GH-49760: Document differences between bugs and security vulnerabilities#49761
GH-49760: Document differences between bugs and security vulnerabilities#49761alamb wants to merge 3 commits intoapache:mainfrom
Conversation
|
Thanks for opening a pull request! If this is not a minor PR. Could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project. Then could you also rename the pull request title in the following format? or See also: |
|
@github-actions crossbow submit preview-docs |
alamb
changed the title
|
Revision: 705ce5c Submitted crossbow builds: ursacomputing/crossbow @ actions-a1e6cabe5e
|
|
I think such guidelines should really be implementation-specific. Some implementations may want to have different opinions on what deserves a CVE and the associated ceremonial. |
I am happy to close this PR if others agree (or want this to be targeted just at the C/C++ implementation) I made a PR for arrow-rs here and I can incorporate the guidance there too |
|
|
||
| * Execute arbitrary code (RCE); | ||
| * Exfiltrate sensitive information from process memory (Information Disclosure); | ||
| * Cause a sustained Denial of Service (DoS) affecting the broader system. |
There was a problem hiding this comment.
Here we define DoS as an exploitable issue, but then say that process crashes are not exploitable?
I think what gets tricky is technically any arrow API could be exposed by a client application, and therefore in theory could be exploitable in that applications context.
I wonder if we need to distinguish between network APIs, e.g. arrow flight, and internal APIs?
There was a problem hiding this comment.
yeah, I was hedging with "sustained" and "affecting the broader system" . I guess in my mind I don't think we should treat panics or OOMs as security issues (they are bugs certainly)
I want it to be clear to downstream users that they need to take other precautions (like process sandboxing, and cgroups for example) to make their systems resilent rather than assume we will treat every bug as a security issue
There was a problem hiding this comment.
Maybe we should just remove "denial of service" from the list 🤔
github-actions
bot
added
awaiting changes
3 participants
Rationale for this change
The current security model documented https://arrow.apache.org/docs/dev/format/Security.html
Does not explicitly address what constitutes a bug vs a security vulnerability. We should make this clear
This is a follow on to the security documentation added by @pitrou in
What changes are included in this PR?
Add a section to the format security document that defines bugs vs security vulnerabilitty
Are these changes tested?
Not sure
Are there any user-facing changes?
Yes as it defines our security posture more generally